Build succeeded (check pipeline).

Coverage increased (+0.08%) to 86.284% when pulling 28a7fd6 on jeskepetr:WA-12423 into b6f1569 on gooddata:master.

Please do not use GoodData internal tickets in PRs/commits for this "really public" OSS library. Create GitHub issue instead and add there the description of problem/feature and possibly, if you need to, link the internal ticket within this issue.

See comments below.
Also, I'm just wondering what's the purpose of this not-AuditEvent bean and its special API endpoint? As I can see, it still represents a part audit log (GD internally - CFAL)...

@peter-plochan It is part of cfal, but they are special events/acces logs directly from haproxy that represents access logs for particular hosts. In this case you do not have domain and user context. So if you try to reuse AuditLog then you will have to change whole logic behind AuditLogs because they are build upon domain and user. The API also will support Common Log Format, so it is really access logs to particular host.

See comments below.
Also, I'm just wondering what's the purpose of this not-AuditEvent bean and its special API endpoint? As I can see, it still represents a part audit log (GD internally - CFAL)...

@peter-plochan It is part of cfal, but they are special events/acces logs directly from haproxy that represents access logs for particular hosts. In this case you do not have domain and user context. So if you try to reuse AuditLog then you will have to change whole logic behind AuditLogs because they are build upon domain and user. The API also will support Common Log Format, so it is really access logs to particular host.

Ahh, ok, thanks for the explanation @mverbovsky

So the question is, if this whole thing should or should not share the Java package with the other audit log entities (AuditEvent).

See comments below.
Also, I'm just wondering what's the purpose of this not-AuditEvent bean and its special API endpoint? As I can see, it still represents a part audit log (GD internally - CFAL)...

@peter-plochan It is part of cfal, but they are special events/acces logs directly from haproxy that represents access logs for particular hosts. In this case you do not have domain and user context. So if you try to reuse AuditLog then you will have to change whole logic behind AuditLogs because they are build upon domain and user. The API also will support Common Log Format, so it is really access logs to particular host.

Ahh, ok, thanks for the explanation @mverbovsky

So the question is, if this whole thing should or should not share the Java package with the other audit log entities (AuditEvent).

I would vote for the same package, because it is still part of audit logging.

Build succeeded (check pipeline).

Build succeeded (check pipeline).

Build succeeded (check pipeline).

Build succeeded (gate pipeline).

• https://checklist.intgdc.com/job/compliance/job/gooddata-java-merge-compliance-check/213/ : SUCCESS in 26s
• https://checklist.intgdc.com/job/compliance/job/gooddata-java-fossa-scanning-zuul-el7/53/ : SUCCESS in 21s (non-voting)